Skip to content

feat(xml/unstable): add XML parsing and serialization module #6942

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
tomas-zijdemans wants to merge 3 commits into
base: main
Choose a base branch
from
Open

feat(xml/unstable): add XML parsing and serialization module #6942

tomas-zijdemans wants to merge 3 commits into from
+18,733 −2

Conversation

@tomas-zijdemans
Copy link
Contributor

@tomas-zijdemans tomas-zijdemans commented Jan 7, 2026 •
edited
Loading

New XML parsing and serialization module

What @std/xml has:

  • Streaming parser, DOM-style parser, serialization
  • Browser compatible, position tracking, spec-compliant

What @std/xml doesn't Have:

  • Namespace resolution, DTD/Schema validation, HTML entities
  • Custom entities, XPath/selectors, object-to-XML builder

Benchmark Results

My personal use case is a 600MB file of product data in a Google Shopping/Merchant XML format. I use Sax for this, since it can stream. Therefore, I picked Sax and fast-xml-parser (widely used for non-streaming) as the reference cases. Please leave a comment if you would like to see a comparison to another package.

I ran these benchmarks a few hundred times (except the big streaming test that I ran about 15-20 times). All on a MacBook M1 Max. The test files are located in testdata (not the 600MB one naturally)

Small Files (<10KB)

Parser Time vs Baseline
Deno std xml 0.015ms baseline
SAX 0.027ms 1.8x slower
fast-xml-parser 0.042ms 2.8x slower

Large Files (large.xml - 300KB)

Parser Time vs Baseline
Deno std xml 3.03ms baseline
SAX 7.40ms 2.4x slower
fast-xml-parser 11.05ms 3.6x slower

Streaming (597MB file)

Parser Time Throughput vs Baseline
Deno std xml 8.37s 91.0K products/s baseline
SAX 17.04s 44.5K products/s 2.0x slower

@tomas-zijdemans tomas-zijdemans requested a review from kt3k as a code owner January 7, 2026 22:09
@crowlKats
Copy link
Member

crowlKats commented Jan 8, 2026

could we get some benchmarks comparing to other parsers?

@tomas-zijdemans
Copy link
Contributor Author

tomas-zijdemans commented Jan 8, 2026

could we get some benchmarks comparing to other parsers?

Yes, that's a good idea. I'll look into it.

@codecov
Copy link

codecov bot commented Jan 8, 2026 •
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.55%. Comparing base (6b93b78) to head (a5ed5bf).

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #6942      +/-   ##
==========================================
+ Coverage   94.28%   94.55%   +0.26%     
==========================================
  Files         584      593       +9     
  Lines       43186    44968    +1782     
  Branches     6933     7390     +457     
==========================================
+ Hits        40720    42519    +1799     
+ Misses       2413     2397      -16     
+ Partials       53       52       -1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@tomas-zijdemans
Copy link
Contributor Author

tomas-zijdemans commented Jan 8, 2026

could we get some benchmarks comparing to other parsers?

Updated the description now. Let me know if you would like to benchmark against a specific package

@tomas-zijdemans tomas-zijdemans force-pushed the xml branch 6 times, most recently from 7f792e6 to e20f201 Compare January 8, 2026 21:04
tomas-zijdemans
tomas-zijdemans commented Jan 8, 2026
View reviewed changes
import_map.json
Copy link
Contributor Author

@tomas-zijdemans tomas-zijdemans Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I have no idea why this formatting is happening 😅

@timreichen
Copy link
Contributor

timreichen commented Jan 8, 2026

Ref: denoland/deno#24995
There was no reply if DOMParser or something similar was to be implemented in deno, so I like this PR in general.
However, it might be worth to check with the deno core team what their current stance is on this before merging anything.

@tomas-zijdemans
Copy link
Contributor Author

tomas-zijdemans commented Jan 9, 2026

Ref: denoland/deno#24995 There was no reply if DOMParser or something similar was to be implemented in deno, so I like this PR in general. However, it might be worth to check with the deno core team what their current stance is on this before merging anything.

Thanks, I was not aware of this discussion. Perhaps we could have it as an unstable module for now? Then we can always kick it out, should the core team decide to implement DOMParser

@tomas-zijdemans
Copy link
Contributor Author

tomas-zijdemans commented Jan 9, 2026

Updated again to increase streaming performance and get test coverage to 100%

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@kt3k kt3k Awaiting requested review from kt3k kt3k is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@tomas-zijdemans @crowlKats @timreichen